|
|
|
|
|
|
|
The component diagram, which visually documents your ActiveX components |
|
|
|
|
|
|
|
|
The deployment diagram, which visually documents where your ActiveX EXE, Active documents, Active Server Pages, and other out-of-process components reside |
|
|
|
|
|
|
|
|
User and developer guides |
|
|
|
|
|
|
|
|
The iteration/project plan, which will evolve in structure like all your other artifacts |
|
|
|
|
|
|
|
|
Evolving your project artifacts will involve every project stakeholder, including yourself and your team (if applicable), project manager, domain experts and key users, and sometimes executives. At certain points during the earlier part of your project, you will revisit at least 80% of your artifacts at varying degrees of treatment. Again, this number will decrease as your project stabilizes. If you don't often revisit a substantial number of artifacts, the return on investment for your project will diminish, as will the usefulness of your application in the eyes of your users. Of course, you don't want to revisit your artifacts for the sake of doing so or to try to know everything about your users' domain in the first few iterations. Revisit artifacts only when you make significant discoveries about either the domain or the artifacts themselves while evolving them. For an application in which you expect to have fewer then 100 classes, for instance, you might have a dozen or so user meetings (half a dozen beta tests) that will each prompt anywhere from a handful to several dozen or more discoveries. |
|
|
|
|
|
|
|
|
Preserving your artifacts involves knowing enough about your application's purpose to properly manage and evolve the artifacts. A measurement of the preservation of your artifacts can be given by assessing your current knowledge of your use cases. A use case should have many scenarios in the forms of sequence diagrams. If, after elaborating your use cases, you have only one sequence diagram per use case, something is wrong. You can have many sequence diagrams, but look for opportunities to share diagrams between use cases. |
|
|
|
|
|
|
|
|
Finally, as your project evolves, you shouldn't have several hundred use cases. Typically, applications require no more than a few dozen use cases. If you keep in mind that a use case is a meaningful course of events that a user goes through in performing some business process, you should be fine in elaborating your use cases. A well-structured prototype can do wonders in helping you refine your use cases. |
|
|
|
|
|